Size Report

Bundles

Usages

Hello team, could you please help run the ecosystem-ci? Thanks!

/ecosystem-ci run

@jh-leong I've invited you to the team btw. Thank you for your contributions!

📝 Ran ecosystem CI: Open

@johnsoncodehk
This PR has affected the generated type signature of https://github.com/vuejs/language-tools/blob/dc6f943c6ccb26778906a49532966aaf69fdc5a5/test-workspace/component-meta/reference-type-exposed/component.vue#L10 (full log at https://github.com/vuejs/ecosystem-ci/actions/runs/10201662987/job/28224044101#step:7:1006)
Could you update the vue version and the test snapshot in the language-tools repo so that we can make the ecosystem-ci all green again? Thanks!

@jh-leong @yyx990803
It appears this PR has changed the type inference for ref when used with MaybeRef:

import { ref, MaybeRef } from 'vue'

const a: MaybeRef<number> = 1;
const b = ref(a); // Ref<number, MaybeRef<number>>

Shouldn't it be Ref<number, number> instead?

Consider this example as well:

const a: MaybeRef<number> = ref(1);
const b = ref(a); // Ref<number, number | Ref<number, number>>

Hi @mefcorvi, thanks for your feedback.

The behavior in the examples you mentioned is expected, see TypeScript Playground.

I'm not entirely sure what specific issue you're referring to. Could you please create a new issue and provide a concrete example that illustrates the problem? This would help us track and address the issue more effectively.

Thanks.

To be honest, I didn't expect that it was possible to put one ref inside another ref. I was sure that in such cases there would be unwrapping, i.e., b2.value = ref(1) would be equivalent to b2.value = 1, since ref(ref(1)).value === 1. Now I see that this is a valid case, and it is actually possible to have one ref inside another, so the current typing is indeed correct.

I apologize for the confusion and any inconvenience this may have caused. My question is resolved.

@jh-leong After some thought, I conclude that something is indeed broken. Now, it is possible to have code like this, which is correct from a types standpoint but obviously broken. Consider this example:

const b = ref(ref(1));
console.log(b.value.toFixed()); // 1
b.value = ref(2);
console.log(b.value.toFixed()); // runtime error

Here, the type of b is Ref<number, number | Ref<number>>. This means that we can set it to Ref<number>, but the getter is supposed to return number. However, if we set b.value to ref(1), we actually get ref(1) back.

Additionally, I believe that before the change in the current PR, it was not possible to set the value of a ref to another ref because of both setters and getters were UnwrapRef. Looking at the implementation of the ref function, I don't think that having one ref inside another was ever an allowed case.

I will create a separate issue since this PR is already merged.

#8543 (review)

I noticed this PR was merged into main instead of minor. This may require TS > 5.1 in the next patch, so we should move it to minor.

@jh-leong I've reverted this and #11536 in the main branch so we avoid accidentally raising TS version requirements in 3.4.

minor branch has merged main with both this and #11442 applied so they will be part of 3.5.

@jh-leong I've reverted this and #11536 in the main branch so we avoid accidentally raising TS version requirements in 3.4.

minor branch has merged main with both this and #11442 applied so they will be part of 3.5.

I think the main branch has been merged into minor after the revert. I could be wrong, but I don't see both of them in the beta release.